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For: PROVIDING CONTENT DELIVERY DURING A CALL HOLD CONDITION 

APPEAL BRIEF 

Honorable Commissioner for Patents 
Alexandria, VA 22313-1450 

Dear Sir: 

This Appeal Brief is submitted in support of the Notice of Appeal dated October 26, 2005. 

I. REAL PARTY IN INTEREST 

MCI, Inc. is the real party in interest. 



II. RELATED APPEALS AND INTERFERENCES 



Appellant is unaware of any related appeals and interferences. 
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III. STATUS OF THE CLAIMS 

Claims 1-30 are pending in this appeal. No claim is allowed. This appeal is therefore 
taken from the final rejection of claims 1-30 on July 27, 2005. 

IV. STATUS OF AMENDMENTS 

No amendment to the claims has been filed since the final rejection of claims 1-30 on July 
27, 2005. 

V. SUMMARY OF THE CLAIMED SUBJECT MATTER 

The present invention relates to a communications system, and is more particularly related 
to call processing over a data network. (See, e.g., specification, \ 01) 

The popularity and convenience of the Internet has resulted in the reinvention of 
traditional telephony services. These services are offered over a packet switched network with 
minimal or no cost to the users. IP (Internet Protocol) telephony, thus, have found significant 
success, particularly in the long distance market. In general, IP telephony, which is also referred 
to as Voice-over-IP (VOIP), is the conversion of voice information into data packets that are 
transmitted over an IP network. Users also have turned to IP telephony as a matter of convenience 
in that both voice and data services are accessible through a single piece of equipment, namely a 
personal computer. The continual integration of voice and data services further fuels this demand 
for IP telephony applications that support a breath of new services. In addition to the 
development of new services and features, it is recognized that the traditional telephony services 
need to be retained. 

The Session Initiation Protocol (SIP) has emerged to address the signaling of calls over an 
IP network. As an end-to-end protocol, SIP advantageously permits the end nodes with the 
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capability to control call processing. By contrast, traditional telephony services are totally 
controlled by the intermediate network components; that is, the switches, have full control over 
call establishment, switching, and call termination. In the SIP architecture, it is sometimes 
desirable for an intermediate network element to control the call processing. For example, codec 
(coder/decoder) incompatibility may require network intervention to ensure that the exchange of 
packets are meaningful. 

Because of the architectural differences between VOIP systems and conventional 
telephony systems, effecting traditional telephony services, such as music-on-hold, poses a 
challenge in terms of signaling and efficient use of network resources. The music-on-hold feature 
provides the party that is placed on hold to listen to a predetermined catalog of music so that the 
party is aware that the party is on hold. 

In a business setting (e.g., call center applications) a caller's willingness to be placed on 
hold can translate into an increased customer base. The capability for the party to listen to music 
may have a calming effect so that the party does not grow too impatient during the suspension of 
the call. In addition to music, a retailer, for example, may place advertisements (or in place of) to 
alert the party on hold of the products and services that the retailer offers. Therefore, a music-on- 
hold feature has tremendous commercial value. However, this value is greatly diminished if the 
cost of implementation is disproportionate. 

Therefore, there is a need for an approach for efficiently performing a music-on-hold type 
feature in a data communications system. There is also a need to preserve a standard architecture 
to promote deployment of network services, while minimizing system complexity and resources. 
There is also a need to implement telephony services cost effectively. (See, e.g., specification, 
02-06) 
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These and other needs are addressed by the present invention in which a data 
communications system provides a network-based music-on-hold feature. Using an application 
layer protocol, such as the Session Initiation Protocol (SIP), a server, acting as a SIP proxy server, 
communicates with a content server (e.g., a music server) to establish a media session between a 
client that is placed on hold and the content server. Upon establishment of the media session, the 
proxy server instructs the client that placed the call on hold to stop sending media, thereby 
preserving bandwidth. The client that placed the call on hold can specify the content that is to be 
transmitted to the client on hold. The above approach advantageously provides efficient use of 
network resources and improves scalability. (See, e.g., specification ^ 7, claims 1-4, 6-10, 12-16, 
18-22, 24-30) 

In one aspect of the present invention, a data communication system for providing content 
transmission upon placement of a call on hold is disclosed. The system includes a server that is 
configured to receive a message from a first client indicating the hold condition of the call with a 
second client. The system also includes another server that is configured to transmit content 
stored therein to the second client in response to a request message from the server. (See, e.g., 
specification f 8, claim 1) 

In another aspect of the present invention, a method for providing content transmission 
over a data network upon placement of a call on hold is disclosed. The method includes 
receiving a message from a first client indicating the hold condition of the call with a second 
client. Additionally, the method includes transmitting a request message to a content server to 
instruct the content server to transmit content stored therein to the second client. (See, e.g., 
specification K 9, claim 7) 
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In another aspect of the present invention, a network device for providing content 
transmission over a data network upon placement of a call on hold is disclosed. The device 
includes a communications interface that is configured to receive a message from a first client 
indicating the hold condition of the call with a second client. The device also includes a 
processor that is coupled to the communications interface and is configured to generate a request 
message to be transmitted to a content server to instruct the content server to transmit content 
stored therein to the second client. (See, e.g., specification ^ 10, claim 13) 

In another aspect of the present invention, a network device for providing content 
transmission over a data network upon placement of a call on hold is disclosed. The device 
includes means for receiving a message from a first client indicating the hold condition of the call 
with a second client, and means for generating a request message to be transmitted to a content 
server to instruct the content server to transmit content stored therein to the second client. (See, 
e.g., specification ^ 11, claim 19) 

In yet another aspect of the present invention, a computer-readable medium carrying one 
or more sequences of one or more instructions for providing content transmission over a data 
network upon placement of a call on hold is disclosed. The one or more sequences of one or 
more instructions include instructions which, when executed by one or more processors, cause 
the one or more processors to perform the step of receiving a message from a first client 
indicating the hold condition of the call with a second client. Another step includes transmitting 
a request message to a content server to instruct the content server to transmit content stored 
therein to the second client. (See, e.g., specification 12, see also, e.g., specification, fflj 49-56, 
claim 25) 
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FIG. 1 is a diagram of a data communications system including a content server and a 
proxy server to provide a music-on-hold type feature, according to an embodiment of the present 
invention. In particular, the communication system 100 supports IP telephony services among 
multiple user agents 101, 103. The user agents 101, 103 exchange messages over the IP network 
105 during a voice call. A content server 107 stores content that is transmitted to one of the user 
agents 101, 103 during a hold condition of a call between the user agents 101, 103. In an 
exemplary embodiment, the content server 107 stores music files, and hence, may be referred to 
as a music server. Alternatively, the content server 107 may store any type of audio file, such as 
advertisement messages. (See, e.g., specification^ 23, claims 1-3,7, 9, 13, 15, 19, 21, 25, 27) 

The system 100 utilizes a proxy server 109 for establishment of calls among the user 
agents 101, 103 and the content server 107, as described below with respect to FIGs. 3-5. (See, 
e.g., specification 1 24, claims 1, 2, 7, 13, 19 and 25) 

Four possible scenarios exist with the placement of a VOIP call: (1) phone-to-phone, (2) 
phone-to-PC, (3) PC-to-phone, and (4) PC-to-PC. In the first scenario of phone-to-phone call 
establishment, a voice station is switched through PSTN 1 1 1 by la switch to a VOIP gateway (not 
shown), which forwards the call through the IP network 105. The packetized voice call is then 
routed through the IP network 105, exiting the IP network 105 at an appropriate point to enter the 
PSTN 1 1 1 and terminates at a voice station. Under the second scenario, a voice station places a 
call to PC through a switch to the PSTN 111. This voice call is then switched by the PSTN 1 1 1 
to a VOIP gateway (not shown), which forwards the voice call to a PC via the IP network 105. 
The third scenario involves a PC that places a call to a voice station. Using a voice encoder, the 
PC introduces a stream of voice packets into the IP network 105 that are destined for a VOIP 
gateway (not shown). A VOIP gateway (not shown) converts the packetized voice information 
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into a POTS (Plain Old Telephone Service) electrical signal, which is circuit switched to the 
voice station. Lastly, in the fourth scenario, a PC establishes a voice call with a PC; in this case, 
packetized voice data is transmitted from the PC via the IP network 105 to another PC, where the 
packetized voice data is decoded. (See, e.g., specification, f 26) 

The system 100 may employ SIP to exchange messages. {See, e.g., specification U 27, 
claim 2, 5, 8, 11, 14, 17, 20, 23, 26, 29) 

SIP messages are in form of either requests or responses. The user agents 101, 103 may 
behave as either a user agent client (UAC) or a user agent server (UAS), depending on the 
services that the system 100 is executing. In general, a user agent client issues requests, while a 
user agent server provides responses to these requests. {See, e.g., specification, ^ 27) 

According to an embodiment of the present invention, the proxy server 109 provides a 
network-based music-on-hold feature (See, e.g., specification f 30, claims 1, 2, 3, 9, 15, 21, 25, 
27), whereby the proxy server 109 (See, e.g., specification If 30, claim 2) establishes a music 
media session with the content server 107 (See, e.g., specification Tf 30, claims 1,7, 13, 19, 25) 
and the user agent 101, 103 that is on hold. Because the feature is provided by the network, the 
functionalities of the user agents 101, 103 can be simplified. 

FIG. 2 is a diagram of an exemplary protocol architecture employed in the system of FIG. 
1 . The layered nature of the architecture provides protocol separation and independence, whereby 
one protocol can be exchanged or modified without affecting the other higher layer or lower layer 
protocols. It is advantageous that the development of these protocols can occur concurrently and 
independently. 

The foundation of the architecture rests with the IP layer 201. The IP layer 201 provides 
an unreliable, connectionless data delivery service at the network level. The service is 
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"unreliable" in the sense that the delivery is on a "best effort" basis; that is, no guarantees of 
packet delivery are made. IP is the de facto Internet working protocol standard. 

Above the IP layer 201 are the TCP (Transmission Control Protocol) 203 and the UDP 
(User Datagram Protocol) 205. The TCP layer 203 provides a connection-oriented protocol that 
ensures reliable delivery of the IP packets, in part, by performing sequencing functions. This 
sequencing function reorders any IP packets that arrive out of sequence. In contrast, the User 
Datagram Protocol (UDP) 205 provides a connectionless service that utilizes the IP protocol 201 
to send a data unit, known as a datagram. Unlike TCP 203, UDP 205 does not provide 
sequencing of packets, relying on the higher layer protocols to sort the information. UDP 205 is 
preferable over TCP 203 when the data units are small, which saves processing time because of 
the minimal reassembly time. One of ordinary skill in the art would recognize that embodiments 
of the present invention can be practiced using either TCP 203 or UDP 205, as well as other 
equivalent protocols. {See, e.g., specification ffif 32-34, claims 2, 8, 14, 20, 26) 

The next layer in the IP telephony architecture of FIG. 2 supplies the necessary IP 
telephony signaling and includes the H.323 protocol 207 and the Session Initiation Protocol (SIP) 
209. The H.323 protocol 207, which is promulgated by the International Telecommunication 
Union (ITU), specifies a suite of protocols for multimedia communication. SIP 209 is a 
competing standard that has been developed by the Internet Engineering Task Force (IETF). SIP 
209 is a signaling protocol that is based on a client-server model. It should be noted that both the 
H.323 protocol 207 and SIP 209 are not limited to IP telephony applications, but have 
applicability to multimedia services in general. In an embodiment of the present invention, SIP 
209 is used to create and terminate voice calls over an IP network 105. However, it is understood 
that one of ordinary skill in the art would realize that the International Telecommunications 
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Union (ITU) H.323 protocol suite 207 and similar protocols can be utilized in lieu of SIP 209. 
Above SIP 209 is the Session Description Protocol (SDP) 211, which provides information about 
media streams in the multimedia sessions, as to permit the recipients of the session description to 
participate in the session. {See, e.g., specification 32-35, claims 2, 8, 14, 20, 26) 

As seen in FIG. 2, SIP 209 can utilize either TCP 203 or UDP 205. Similar to other IETF 
protocols (e.g., the simple mail transfer protocol (SMTP) and Hypertext Transfer Protocol 
(HTTP)), SIP 209 is a textual protocol. As indicated earlier, SIP 209 is a client-server protocol, 
and as such, clients generate requests that are responded to by the servers. (See, e.g., specification 
U 34, claims 1, 2, 7, 8, 13, 14, 19, 20, 25, 26) 

FIG. 3 is a diagram of a call flow for providing a call hold feature. As shown, a call is 
established between the user agent 101 and the user agent 103. Specifically, in step 301, the user 
agent 101 sends an INVITE message with an associated SDP body (e.g., sdp A) to the proxy 
server 109; "A" refers to the user agent 101. In turn, the proxy server 109, as in step 303, 
forwards the INVITE message to the user agent 103. The proxy server also sends a 100 TRYING 
message, per step 305, to the user agent 101 in response to the received INVITE message. Next, 
in step 307, the user agent 103 sends a 180 RINGING message to the proxy server 109, which the 
forwards the message to the user agent 101 (per steps 307 and 309). The user agent 103, as in 
step 311, transmits a 200 OK with a message body (sdp B) to the proxy server 109; "B" refers to 
the user agent 103. In step 313, the proxy server 109 forwards the 200 OK message to the user 
agent 101, which responds with an acknowledgement (ACK) message, per step 315. The ACK is 
relayed by the proxy server 109 to the user agent 103 (step 317). At this point, a media session 
(i.e., call) is established between the user agent 101 and the user agent 103. (See, e.g., 
specification 37, claims 1, 7, 13, 19 and 25) 
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To invoke a call hold condition, a user associated with the user agent 103 presses a "hold" 
button on a set or selects "hold" from a pull down menu or clicks on a button on a screen. This 
causes the user agent 103 to send a re-INVITE message to the other user agent 101 with the SDP 
indicating a hold state. As a result, the other user agent 101 stops sending media until the call is 
taken off hold by a re-INVITE with connection IP Address of the User Agent. (See, e.g., 
specification H 38, claims 1, 6, 7, 12, 13, 18, 19, 24, 25, 30) 

In particular, in step 319, the user agent 103 (which is placing the user agent 101 on hold) 
sends an INVITE sdp hold message to the proxy server 109 (See, e.g., specification ^ 39, claim 
2), which in turn transmits the message to the user agent 101 (per step 321). In step 323, the 
proxy server 109 sends a 100 TRYING message to the user agent 103. In step 325, the user agent 
101 sends a 200 OK sdp A message to the user agent 103 via the proxy server 109, per steps 325 
and 327. In response, the user agent 103 sends an ACK message to the proxy server 109 (step 
329); the ACK message is then forwarded to the user agent 101, per step 331. Thus, the user 
agent 101 does not transmit any additional media. (See, e.g., specification, 39) 

The above hold feature is modified to introduce a content server, whereby the user agent 
103 controls the call processing, as seen below in FIG. 4. (See, e.g., specification ^ 40, claims 1, 
2,7,8, 13, 14, 19,20,25,26) 

FIG. 4 is a diagram of a call flow for providing a music-on-hold feature via call control at 
a user agent. In this example, a media session is established between the user agent 101 and the 
user agent 103 in similar fashion as in the steps 301-317 of the process of FIG. 3. In step 401, the 
user agent 103 sends an INVITE message to the content (e.g., music) server 107. The server 107, 
in response, sends a 200 OK message with sdp MS (Music Server) to the user agent 103, per step 
403. In step 405, the user agent 103 transmits an INVITE sdp MS message to the proxy server 
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109, which forwards the message to the user agent 101, per step 407. In step 409, the proxy 
server 109 sends a 100 TRYING message to the user agent 103. In step 41 1, the user agent 101 
sends a 200 OK sdp A message to the proxy server 109; the proxy server 109 relays this message 
to the user agent 103, as in step 413. In step 415, the user agent 103 forwards an ACK sdp A 
message to the content server 107, and sends an ACK to the proxy server 109 (step 417). The 
proxy server 109, in step 419, instructs the user agent 101 not to send any further media. {See, 
e.g., specification 1J 41, claims 2, 6, 12, 18, 24 and 30) Accordingly, the server 107 can begin 
transmitting content (e.g., music) to the user agent 101. {See, e.g., specification \ 41, claims 1, 2, 
3, 6, 7, 8, 9, 12, 13, 14, 15, 18, 19, 20, 21, 24, 25, 26, 27, 30) 

In this terminal based approach, the user agent 103 acts as a Back-to-Back User Agent 
(B2BUA) and uses SIP 3pcc (SIP Third Party Call Control) to INVITE a content (e.g., music) 
server 107, which is sent the SDP information of the other user agent 101. The user agent 101 
receives a re-INVITE with hold SDP, and then receives RTP music sent from the server 107. 
Unfortunately, this approach requires processing on the part of the terminal (i.e., user agents 101, 
103). By contrast, the present invention provides a network-based approach (as shown in FIG. 5), 
whereby the complexity of the music-on-hold service resides within the network, not within the 
user terminal. {See, e.g., specification \ 42, claims 1, 7, 13, 19 and 25) 

FIG. 5 is a diagram of a call flow for providing a music-on-hold feature via call control at 
a proxy server, according to an embodiment of the present invention. {See, e.g., specification \ 
42, claims 1, 2, 7, 13, 19 and 25) A media session is established between the user agent 101 and 
the user agent 103 in similar fashion as in the steps 301-317 of the process of FIG. 3. Unlike the 
process of FIG. 4, this process does not impose any additional capabilities on the terminal (i.e., 
user agents 101, 103), requiring only support for the base SIP specification, IETF RFC 2543. As 
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with the process of FIG. 4, when the user presses the "hold" button, the terminal sends a re- 
INVITE. However, in this process, the proxy server 109 intercepts the re-INVITE and performs 
call control (e.g., the SIP 3pcc) with respect to the content server 107, effectively on behalf of the 
user agent 103. When the user takes the remote party off of hold, the proxy server 109 processes 
the re-INVITE with a normal SDP and disconnects the content server 107 from the call. (See, 
e.g., specification U 42, claims 1, 2, 6, 7, 8, 12, 13, 14, 18, 19, 20, 24, 25, 26, 30) 

Specifically, in step 501, the user agent 103 sends an INVITE sdp hold message to the 
proxy server 109, which responds to the user agent 103 with a 100 TRYING message (step 503). 
In step 505, the proxy server 109 contacts the content server 107 with an INVITE message. In 
step 507, the content server 107 (e.g., music server) sends a 200 OK sdp MS (Music Server) 
message to the proxy server 109. Next, the proxy server 109, as in step 509, sends an INVITE 
sdp MS message to the user agent 101. In response to the received INVITE sdp MS message, the 
user agent 101 sends a 200 OK sdp A message, per step 511. In step 513, the proxy server 109 
forwards a 200 OK sdp hold message to the user agent 103. The proxy server 109 sends an ACK 
sdp A message to the content server 107, per step 515. In step 517, the proxy server 109 
transmits an ACK message to the user agent 101. The user agent 103 transmits an ACK message 
to the proxy server 109 in step 519. At this point, the content server 107 can supply content to 
the user agent 101. In this example, the content that is supplied is music, which may be in the 
form of music files or streaming audio files. (See, e.g., specification ^ 44, claims 2, 3, 9, 15, 21 
and 27) 

In an exemplary embodiment, the proxy server 109 may have a number of different music 
selections, from different types of music to company specific sales and information recordings. 
The selection of which music to play can be made by the proxy server 109 based on the From 
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address of the re-INVITE and communicated to the content server 107 by a specific Request-URI 
in the 3pcc INVITE message. The use of a special header in the re-INVITE or a provisioned 
table of From headers by the proxy server 109 permits selection of the type of content to be 
delivered to the user agent 101. {See, e.g., specification ^ 45, claims 2, 5, 1 1, 17, 23 and 29) 

Alternatively, the user agent 103 may select the type of content to play to the user agent 
101 using, for example, a special SIP header extension, which could be of the form "Music-On- 
Hold: classical" or "Music-On-Hold: http://www.music.com/classical-hits.wav" where a URL is 
used to reference a specific music wave file. This header could be either passed on unchanged by 
the proxy server 109 in the 3pcc INVITE, or the header could be translated into a SIP Request- 
URI. (See, e.g., specification f 46, claims 4, 10, 16, 22 and 28) 

Under the above network-based approach for providing music-on-hold, the proxy server 
109 is used to detect the hold condition and invoke 3pcc. The modification of the SDP response 
to the re-INVITE by the proxy server 109 effectuates a reverse hold condition, thereby preventing 
the user agent 103 from sending media to the other user agent 101 - which currently receives 
media from the content server 107. (See, e.g., specification 1J 47, claim 2) 

As indicated previously, the music-on-hold feature may alternatively be implemented 
according to the ITU H.323 protocol suite. (See, e.g., specification | 48, claims 2, 8, 14, 20 and 
26) 

Accordingly, a network-based music-on-hold feature is provided in which a proxy server 
performs call control to establish a media session between a content server and the user agent that 
is on-hold. This approach advantageously reduces the complexity of the terminals (e.g., SIP 
phones) and enhances scalability, while maintaining a standardized architecture. (See, e.g., 
specification, f 57) 
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VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Whether claims 1, 3, 4, 6, 7, 9, 10, 12, 13, 15, 16, 18, 19, 21, 24, 25, 27, 28 and 30 are 
obvious under 35 U.S.C. § 103(a) based on Kozdon et al. (U.S. 6,456,601) in view of Flockhart 
etal. (U.S. 6,820,260). 

Whether claims 2, 8, 14, 20 and 26 are obvious under 35 U.S.C. § 103(a) based on 
Kozdon et al. and Flockhart et al. and further in view of Anjum et al. (U.S. Patent Application 
Publication No. 2001/0028654 Al). 

Whether claims 5, 11, 17, 23 and 29 are obvious under 35 U.S.C. § 103(a) based on 
Kozdon et al. and Flockhart et al. and further in view of Hazenfield (U.S. 5,991,374). 

VII. ARGUMENT 

A. CLAIMS 1-30 ARE NOT RENDERED OBVIOUS OVER ANY 
COMBINATION OF KOZDON ET AL., FLOCKART ET AL., ANJUM ET 
AL.. OR HAZENFIELD. __ 

The initial burden of establishing a prima facie basis to deny patentability to a claimed 
invention under any statutory provision always rests upon the Examiner. In re Mayne, 104 F.3d 
1339, 41 USPQ2d 1451 (Fed .Cir. 1997); In re Deuel, 51 F.3d 1552, 34 USPQ2d 1210 (Fed. Cir. 
1995); In re Bell, 991 F.2d 781, 26 USPQ2d 1529 (Fed. Cir. 1993); In re Oetiker, 977 F.2d 1443, 
24 USPQ2d 1443 (Fed. Cir. 1992). In rejecting a claim under 35 U.S.C. § 103, the Examiner is 
required to provide a factual basis to support the obviousness conclusion. In re Warner, 379 F.2d 
1011, 154 USPQ 173 (CCPA 1967); In re Lunsford, 357 F.2d 385, 148 USPQ 721 (CCPA 1966); 
In re Freed, 425 F.2d 785, 165 USPQ 570 (CCPA 1970). 

Obviousness rejections require some evidence in the prior art of a teaching, motivation, or 
suggestion to combine and modify the prior art references. See, e.g., McGinley v. Franklin 
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Sports, Inc., 262 F.3d 1339, 1351-52, 60 USPQ2d 1001, 1008 (Fed. Cir. 2001); Brown & 
Williamson Tobacco Corp. v. Philip Morris Inc., 229 F.3d 1120, 1124-25, 56 USPQ2d 1456, 
1459 (Fed. Cir. 2000); In re Dembiczak, 175 F.3d 994, 999, 50 USPQ2d 1614, 1617 (Fed. Cir. 
1999). 

The Patent Office must give specific reasons why one of ordinary skill in the art would 
have been motivated to combine the references. See, e.g., In re Kotzab, 217 F.3d 1365, 1371, 55 
USPQ2d 1313, 1317 (Fed. Cir. 2000); In re Rouffet, 149 F.3d 1350, 1359, 47 USPQ2d 1453, 
1459 (Fed. Cir. 1998). 

1. Claims 1, 3, 4, 6, 7, 9, 10, 12, 13, 15, 16, 18, 19, 21, 24, 25, 27, 28 and 30 
are not rendered obvious over Kozdon et al in view of Flockart et al 



a. Independent claims 1, 7, 13, 19, and 25 are not rendered 
obvious over Kozdon et al in view of Flockart et al 

Independent claim 1 recites "a server configured to receive a message from a first client 
indicating the hold condition of the call with a second client; and another server configured to 
store the content" and "wherein the server is configured to generate a request message, in 
response to the hold condition, for performing call control on behalf of the first client by 
transmitting the request message to the other server to instruct the other server to transmit the 
content to the second client." Claims 7 and 25 recite "generating a request message, in response 
to the hold condition, for performing call control on behalf of the first client" and "transmitting 
the request message to a content server to instruct the content server to transmit content 
stored therein to the second client." Claim 13 recites "a processor coupled to the 
communications interface and configured to generate a request message, in response to the hold 
condition, for performing call control on behalf of the first client by transmitting the request 
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message to a content server to instruct the content server to transmit content stored therein to 

the second client." Also, claim 19 recites "means for generating a request message, in response 

to the hold condition, for performing call control on behalf of the first client" and "means for 

transmitting the request message to a content server to instruct the content server to transmit 

content stored therein to the second client." 

In stark contrast, Kozdon et al discloses a system of providing call progress tones in a 

packetized network include storing the call progress tones and pre-programmed audio deliveries 

at a first device and includes multicasting or broadcasting the tones and deliveries from the first 

device to a number of telephony-enabled devices (Abstract and FIG. 2; see also col. 5: 29-63). 

Specifically, with respect to operation of the proxy server 40 (FIG. 2), Kozdon et al, col. 5: 32- 

53, states the following {emphasis added): 

An alternative embodiment is shown in FIG. 2. The network environment includes 
two proxies 40 and 42 that are positioned so as to be near the points at which the 
call progress tones or audio deliveries are to be transmitted. The call progress 
tones and deliveries are still multicast from the server 10 in combination with the 
router 12, but the proxies are used to receive and process the multicasts. In the 
scenario in which the telephone 24 is engaged in an ongoing call with the remote 
telephone 34, but the caller at the telephone 24 wishes to enter into a short 
consultation call with the person at telephone 16, the proxy 40 may be used. When 
the original telephone call goes on hold, the first call is transferred to the 
proxy 40. The telephone 24 uses CTI messages to control the playback of the 
call progress tones or audio deliveries to the party at telephone 34 from the 
proxy 40. The proxy 40 uses the system-wide multicast announcement service 
from the server 10. The proxies may be low cost devices, since they do not need to 
have the capability to create or store announcements, music-on-hold and call status 
tones. The proxy units may be small units, because they rely upon the multicast 
service. 

As clearly indicated in the above passages, the proxy server 40 merely receives and 
processes the multicasts, while the called telephone 24 controls the call. Consequently, it is not 
possible that server 40 performs any call control, much less in the manner claimed. 
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The Examiner (Office Action dated July 27, 2005, p. 4, item 9) correctly acknowledges 

(emphasis added), "Kozdon does not expressly disclose that the first server generates a request 

message or simply forwards a request message from another unit or that the second server 

transmits the content directly to the second client." However, the Examiner (Office Action 

dated July 27, 2005, p. 4, item 9) then states: 

Flockhart teaches a method (abstract) of providing content and applets to callers 
on hold (col. 1, line 1 - col. 2, line 65), where a first party (Fig. 1, #109) is called 
by a second party (Fig. 1, #99 and #100), and contacts an on-hold handling server 
(Fig. 1, #107) which then contacts a content server (Fig. 1, #103) separate from 
107 (col. 3, lines 50-53), in which 107 sends information to 103 (col. 4, lines 25- 
27) and 103 determines the content to provide to the caller (col. 4, lines 27-50). 
At the time the invention was made, one of ordinary skill in the art would have 
added Flockhart' s server separation method to Kozdon in order to ensure that the 
on-hold server's resources are not tied up (col. 1, lines 20-30). 

Flockhart et al, at col. 3: 49-54, states: 

According to the invention, ACD 107 stores in its memory a plurality of applets 
96-98 and an executable applet-selection function 103. Alternatively, applets 
96-98 and function 103 may be implemented by a separate adjunct processor 
which cooperates with ACD 107. Applet 96 is a negotiation applet, described 
further below. 

As best understood, the Examiner (Office Action dated July 27, 2005, p. 4, item 9) 

equates the "server" as recited by claim 1 with the ACD 107 of Flockhart et al and the "another 

server" as recited by claim 1 with the "separate adjunct processor which cooperates with ACD 

107" mentioned by Flockhart et al However, Flockhart et al (col. 4: 4-14) states: 

Function 103 causes ACD 107 to negotiate an in-queue or on-hold wait 
time with client 100, at steps 204 and 206. This illustratively involves EWT 
function 113 making an estimate (at one or more levels of service, where lower 
service equals longer wait time) of the expected wait time that the call will spend 
in queue or on hold waiting for an agent, and then downloading a negotiation 
applet 96 to client 100 that notifies client 100 of the estimated wait times and 
gives the client an option of agreeing to one of the wait times or not agreeing to 
the wait times and instead selecting being called back at a later time. 
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Function 103 then selects one or more of the applets 97-98 whose execution time satisfies 
the negotiated wait time (col. 4: 27-29). According to Flockhart et al (col. 4: 46-49, emphasis 
added), "Once the applet 98 has be [sic] selected and customized, function 103 causes ACD 107 
to send that applet 98 to client 100 for execution." Thus, any "content" transmitted thereby to 
client 100 of Flockhart et al is transmitted to client 100 by the ACD 107, and not by the 
"separate adjunct processor which cooperates with ACD 107." Thus, there is no suggestion by 
Flockhart et al of "wherein the server is configured to generate a request message, in response to 
the hold condition, for performing call control on behalf of the first client by transmitting the 
request message to the other server to instruct the other server to transmit the content to the 
second client" as recited by claim 1, and the deficiency is not cured by any combination of 
Kozdon et al and Flockhart et al 

The Examiner (Advisory Action dated October 14, 2005, p. 2, item 11) states {emphasis 

added): 

Applicant argues that "the server .... instructs the other server to transmit the 
content to the second client" is not expressly disclosed. As stated, we are using 
the adjunct processor, wherein the functions are separated. The claim language 
does not state that the other server must transmit the content to the second client 
directly. Furthermore, the description above regards an arbitrary separation of 
functionality in which any change may be considered obvious via separation of 
parts. Because 103 forces the transmission, the examiner treats it as a direct 
connection. 

As best understood, this assertion by the Examiner in the Advisory Action contradicts the 
Examiner's previous apparent reliance on col. 3: 51-53 of Flockhart et al as teaching a "content 
server (Fig. 1, #103) separate from 107." (Office Action dated July 27, 2005, p. 4, item 9) Col. 
3: 51-53 of Flockhart et al states, "[alternatively, applets 96-98 and function 103 may be 
implemented by a separate adjunct processor which cooperates with ACD 107." However, 
Appellant respectfully submits that claim 1 clearly recites, "a server configured to receive a 
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message from a first client indicating the hold condition of the call with a second client; and 
another server configured to store the content" and "wherein the server is configured to 
generate a request message, in response to the hold condition, for performing call control on 
behalf of the first client by transmitting the request message to the other server to instruct 
the other server to transmit the content to the second client." Contrary to the Examiner's 
assertions that "any change may be considered obvious via separation of parts," claim 1 
specifically requires that the "other server" is "configured to store the content" and that "the 
server" transmits "the request message to the other server to instruct the other server to 
transmit the content to the second client." These features are neither disclosed nor suggested 
by Flockhart et al. nor by any reasonable combination of Kozdon et al. and Flockhart et al. To 
establish prima facie obviousness of a claimed invention, all of the claim limitations must be 
taught or suggested by the prior art. In re Royka, 490 F.2d 981, 180 USPQ 580 (CCPA 1974). 

Therefore, Appellant respectfully requests that the obviousness rejection of independent 
claim 1 be reversed. 

For reasons similar to those discussed previously, the obviousness rejection of 
independent claims 7, 13, 19, and 25 should also be reversed. 

b. Dependent claims 3, 4, 6, 9, 10, 12, 15, 16, 18, 21, 24, 27, 28 and 
30 are not rendered obvious over Kozdon et al in view of 
Flockart et al. 

The rejection of dependent claims 3, 4, 6, 9, 10, 12, 15, 16, 18, 21, 22, 24, 27, 28, and 30 
should be reversed for at least the same reasons as those discussed above with regard to their 
respective independent claims, and these claims are separately patentable on their own merits. 
For example, the Examiner (Office Action dated July 27, 2005, p. 4, item 11) states, "[f]or claims 
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4, 10, 16, 22, 28, Kozdon teaches that the first client selects the content for transmission to the 
second client (col. 6, lines 3-5)." However, the Examiner (Office Action dated July 27, 2005, p. 
4, item 9) equates the "first client" recited by claim 1 with the call-center agent position 109 of 
Flockhart et al 9 and the "second client" recited by claim 1 with the Internet phone 99 and client 
100 of Flockhart et al. As discussed at col. 3: 58-61, the function 103 (shown in the ACD 107, 
and not 109) of Flockhart et al selects one or more of the applets 97-98 to be sent to the client 
100. Furthermore, the negotiation applet 96, which is downloaded to the client 100, allows the 
client 100 to select an in-queue experience (e.g., music) (col. 4: 10-24). Nowhere does Flockhart 
et al disclose or suggest the call-center agent position 109 selecting content for transmission to 
the client 100 as urged by the Examiner. Unless the patent otherwise provides, a claim term 
cannot be given a different meaning in the various claims of the same patent. Georgia Pacific 
Corp. v. U.S. Gypsum Co., Nos. 97-1238,-1244 (Fed. Cir., Nov. 1, 1999); see also Southwall 
Tech., Inc. v. Cardinal IG Co., 54 F.3d 1570, 1579, 34 USPQ2d 1673, 1679 (Fed. Cir. 1995) 
(holding that claim term found in different claims must be interpreted consistently); Fonar Corp. 
v. Johnson & Johnson, 821 F.2d 627, 632, 3 USPQ2d 1109, 1113 (Fed. Cir. 1987.) (holding that 
a term used in one claim had the same meaning in another claim). Further, to establish prima 
facie obviousness of a claimed invention, all of the claim limitations must be taught or suggested 
by the prior art. In re Royka, 490 F.2d 981, 180 USPQ 580 (CCPA 1974). The Examiner has 
not met his burden in this regard. 

Further, Appellant respectfully submits that Flockhart et al teaches away from the 
combination of Kozdon et al in view of Flockhart et al. suggesting this feature, as the function 
103 (shown in the ACD 107, and not 109) of Flockhart et al selects one or more of the applets 
97-98 to be sent to the client 100. Moreover, the negotiation applet 96, which is downloaded to 
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the client 100, allows the client 100 to select an in-queue experience (e.g., music) (col. 4: 10-24). 
Flockhart et al (per Abstract) specifically states, "[w]hen a call to a call center is enqueued to 
await an agent or placed on hold by an agent, an applet customized to satisfy an in-queue 
experience selected by the caller is downloaded to and executed on the caller's terminal." 

As clearly stated by the MPEP § 2141.02, "Ascertaining the differences between the prior 
art and the claims at issue requires interpreting the claim language, and considering both the 
invention and the prior art references as a whole." Further, "In determining the differences 
between the prior art and the claims, the question under 35 U.S.C. 103 is not whether the 
differences themselves would have been obvious, but whether the claimed invention as a whole 
would have been obvious. Stratoflex, Inc. v. Aeroquip Corp., 713 F.2d 1530, 218 USPQ 871 
(Fed. Cir. 1983); Schenckv. Nortron Corp., 713 F.2d 782, 218 USPQ 698 (Fed. Cir. 1983)" 

Moreover, it is improper to combine references where the references teach away from 
their combination. In re Grasselli, 713 F.2d 731, 218 USPQ 769 (Fed. Cir. 1983). A prior art 
reference must be considered in this entirety including portions that would lead away from the 
claimed invention. W.L. Gore & Associates, Inc. v. Garlock, Inc., 721 F.2d 1540, 220 USPQ 303 
(Fed. Cir. 1983), cert, denied, 469 U.S. 851 (1984). If a proposed modification would render the 
prior art being modified unsatisfactory for its intended purpose, then there is no suggestion or 
motivation to make the proposed modification. In re Gordon, 733 F.2d 900, 221 USPQ 1125 
(Fed. Cir. 1984). If the proposed modification or combination of the prior art would change the 
principle of operation of the prior art invention being modified, then the teachings of the 
references are not sufficient to render the claims prima facie obvious. In re Ratti, 270 F.2d 810, 
123 USPQ 349 (CCPA 1959). MPEP § 2143.01 As the Examiner's assertion regarding Kozdon 
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et al teaches away from its combination with Flockhart et al. at least with regard to claims 4, 10, 

16, 22, 28, the rejection is unsustainable. 

The Examiner further contends (Advisory Action dated October 14, 2005, p. 2, item 1 1): 

Applicant argues that Flockhart teaches away from the first client selecting the 
content for transmission. While it is true that Flockhart teaches some content 
selection features at the server end, Function 103 occurs due to a command from 
the client such as an on-hold command. While it is true that the particular content 
selection may be refined by the server and/or the second client, this does not 
detract from the issue that the first client has some control over the content chosen. 
Further, given the amount of control the second client is given, providing content 
control to the first client would not render the prior art being modified 
unsatisfactory [sic] for its intended purpose. Such control would in fact fulfill the 
purpose of providing appropriate on-hold messages to the second client, especially 
since the first client would have access to information that may influence the 
decision. As an example, the first client might want the second client to take a 
survey during the hold period, and then review the results (col. 5, lines 1-20). 

However, these assertions by the Examiner are merely wishful contentions using 
impermissible hindsight, which are neither disclosed nor suggested by the applied references. 
Obviousness rejections require some evidence in the prior art of a teaching, motivation, or 
suggestion to combine and modify the prior art references. See, e.g., McGinley v. Franklin 
Sports, Inc., supra; Brown & Williamson Tobacco Corp. v. Philip Morris Inc., supra; In re 
Dembiczak, supra. 

To the extent that the Examiner relies on "common knowledge" for his assertions, 
Appellant respectfully submits that the APA requires the Patent Office to articulate and place on 
the record the "common knowledge" used to negate patentability. In re Zurko, 258 F.3d 1379, 
1386, 59 USPQ2d 1693, 1697 (Fed. Cir. 2001)). In re Lee, 277 F.3d 1338, 1344-45, 61 USPQ2d 
1430, 1434-35 (Fed. Cir. 2002). Ordinarily, there must be some form of evidence in the record to 
support an assertion of common knowledge. See, e.g., Lee, 277 F.3d at 1344-45, 61 USPQ2d at 
1434-35 (Fed. Cir. 2002); Zurko, 258 F.3d at 1386, 59 USPQ2d at 1697 (holding that general 
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conclusions concerning what is "basic knowledge" or "common sense" to one of ordinary skill in 
the art without specific factual findings and some concrete evidence in the record to support these 
findings will not support an obviousness rejection). 

Moreover, Appellant asserts that the reasoning that the Examiner puts forth for the 
rejection with respect to "first client" and "second client" contravenes 35 U.S.C. § 132, which 
requires the Director to "notify the applicant thereof, stating the reasons for such rejection." This 
section is violated if the rejection "is so uninformative that it prevents the applicant from 
recognizing and seeking to counter the grounds for rejection." Chester v. Miller, 906 F.2d 1574, 
15 USPQ2d 1333 (Fed. Cir. 1990). This policy is captured in the Manual of Patent Examining 
Procedure. For example, MPEP § 706 states that "[t]he goal of examination is to clearly 
articulate any rejection early in the prosecution process so that applicant has the opportunity to 
provide evidence of patentability and otherwise respond completely at the earliest opportunity." 
Furthermore, MPEP § 706.02Q) indicates that: "[i]t is important for an examiner to properly 
communicate the basis for a rejection so that the issues can be identified early and the applicant 
can be given fair opportunity to reply." 

Thus, at least with regard to claims 4, 10, 16, 22, 28, the rejection is unsustainable and 
should be reversed. 

Furthermore, as none of the reasons proferred by the Examiner with regard to the rejection 
of dependent claims 3, 4, 6, 9, 10, 12, 15, 16, 18, 21, 22, 24, 27, 28, and 30 cure the deficiencies 
of the applied references discussed previously, the rejection of dependent claims 3, 4, 6, 9, 10, 12, 
15, 16, 18, 21, 22, 24, 27, 28, and 30 should be reversed for at least the same reasons as those 
discussed above with regard to their respective independent claims. 



23 



10/016,110 



Patent 



2. Claims 2, 8, 14, 20 and 26 are not rendered obvious over Kozdon et aL 
and Flockart et aL further in view of Anium et aL 

As regards the obviousness rejection of dependent claims 2, 8, 14, 20, and 26, Appellant 
notes that the addition of Anjum et aL, directed (per Abstract) to rapid development of next 
generation telephony services, does not fill in the gaps of Kozdon et aL and Flockhart et aL as 
discussed previously. Anjum et aL is applied for a general teaching of the Session Initiation 
Protocol (Office Action dated July 27, 2005, p. 5, item 14). To establish prima facie obviousness 
of a claimed invention, all of the claim limitations must be taught or suggested by the prior art. 
In re Royka, supra. 

Therefore, the rejection of claims 2, 8, 14, 20 and 26 should be reversed for at least the 
same reasons as those discussed above with regard to their respective independent claims. 

3. Claims 5, 11, 17, 23 and 29 are not rendered obvious over Kozdon et aL 
and Flockart et aL further in view of Hazenfield. 

With respect to the obviousness rejection of dependent claims 5, 11, 17, 23, and 23, 
Appellant submits that the secondary reference of Hazenfield, directed (per Abstract) to a 
remotely programmable message delivery system, does not fill the gaps of Kozdon et aL and 
Flockhart et aL discussed previously with regard to their respective independent claims. The 
Examiner (Office Action dated July 27, 2005, p. 5, item 16) applied Hazenfield for a supposed 
disclosure of selecting and generating content for music-on-hold systems. To establish prima 
facie obviousness of a claimed invention, all of the claim limitations must be taught or suggested 
by the prior art. In re Royka, supra. 

Accordingly, the obviousness rejection of claims 5, 1 1, 17, 23 and 29 should be reversed. 
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VIII. CONCLUSION AND PRAYER FOR RELIEF 



For the foregoing reasons, Appellant 
each of the Examiner's rejections. 

Date 



respectfully requests the Honorable Board to 



Respectfully Submitted, 



DITTHAVONG & CARLSON, P.C. 




Attorney for Appellant(s) 
Reg. No. 41,946 



10507 Braddock Rd, Suite A 
Fairfax, VA 22032 
Tel. 703-425-8508 
Fax. 703-425-8518 
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IX. CLAIMS APPENDIX 

1 . (Previously Presented) A data communication system for providing content 
transmission upon placement of a call on hold, the system comprising: 

a server configured to receive a message from a first client indicating the hold condition 
of the call with a second client; and 

another server configured to store the content, 

wherein the server is configured to generate a request message, in response to the hold 
condition, for performing call control on behalf of the first client by transmitting the request 
message to the other server to instruct the other server to transmit the content to the second client. 

2. (Original) A system according to claim 1, wherein the server is configured to perform 
a proxying function according to an application layer protocol that includes a Session Initiation 
Protocol. 

3. (Original) A system according to claim 1, wherein the content includes at least one of 
music and messaging. 

4. (Original) A system according to claim 1, wherein the first client selects the content 
for transmission to the second client. 
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5. (Original) A system according to claim 4, wherein the selected content is specified in 
a header of a Session Initiation Protocol (SIP) message from the first client to the server. 



6. (Original) A system according to claim 1, wherein the server sends a signaling 
message to the first client to instruct the first client to cease sending media to the second client. 

7. (Previously Presented) A method for providing content transmission over a data 
network upon placement of a call on hold, the method comprising: 

receiving a message from a first client indicating the hold condition of the call with a 
second client; 

generating a request message, in response to the hold condition, for performing call 
control on behalf of the first client; and 

transmitting the request message to a content server to instruct the content server to 
transmit content stored therein to the second client. 

8. (Original) A method according to claim 7, wherein the receiving step is performed 
according to an application layer protocol that includes a Session Initiation Protocol. 

9. (Original) A method according to claim 7, wherein the content in the transmitting step 
includes at least one of music and messaging. 

10. (Original) A method according to claim 7, wherein the first client in the receiving 
step selects the content for transmission to the second client. 
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11. (Original) A method according to claim 10, wherein the selected content is specified 
in a header of a Session Initiation Protocol (SIP) message from the first client. 

12. (Original) A method according to claim 7, further comprising: 

sending a signaling message to the first client to instruct the first client to cease sending 
media to the second client. 

13. (Previously Presented) A network device for providing content transmission over a 
data network upon placement of a call on hold, the device comprising: 

a communications interface configured to receive a message from a first client indicating 
the hold condition of the call with a second client; and 

a processor coupled to the communications interface and configured to generate a request 
message, in response to the hold condition, for performing call control on behalf of the first client 
by transmitting the request message to a content server to instruct the content server to transmit 
content stored therein to the second client. 

14. (Previously Presented) A device according to claim 13, wherein the communications 
interface receives the message according to an application layer protocol that includes a Session 
Initiation Protocol. 

15. (Previously Presented) A device according to claim 13, wherein the content includes 
at least one of music and messaging. 
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16. (Previously Presented) A device according to claim 13, wherein the first client 
selects the content for transmission to the second client. 

17. (Previously Presented) A device according to claim 16, wherein the selected content 
is specified in a header of a Session Initiation Protocol (SIP) message from the first client. 

18. (Previously Presented) A device according to claim 13, wherein the processor 
generates a signaling message to the first client to instruct the first client to cease sending media 
to the second client. 

19. (Previously Presented) A network device for providing content transmission over a 
data network upon placement of a call on hold, the device comprising: 

means for receiving a message from a first client indicating the hold condition of the call 
with a second client; and 

means for generating a request message, in response to the hold condition, for performing 
call control on behalf of the first client; and 

means for transmitting the request message to a content server to instruct the content 
server to transmit content stored therein to the second client. 

20. (Previously Presented) A device according to claim 19, wherein the receiving means 
receives the message according to an application layer protocol that includes a Session Initiation 
Protocol. 
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21. (Previously Presented) A device according to claim 19, wherein the content includes 
at least one of music and messaging. 

22. (Previously Presented) A device according to claim 19, wherein the first client 
selects the content for transmission to the second client. 

23. (Previously Presented) A device according to claim 22, wherein the selected content 
is specified in a header of a Session Initiation Protocol (SIP) message from the first client. 

24. (Previously Presented) A device according to claim 19, wherein the generating 
means generates a signaling message to the first client to instruct the first client to cease sending 
media to the second client. 

25. (Previously Presented) A computer-readable medium carrying one or more sequences 
of one or more instructions for providing content transmission over a data network upon 
placement of a call on hold, the one or more sequences of one or more instructions including 
instructions which, when executed by one or more processors, cause the one or more processors 
to perform the steps of: 

receiving a message from a first client indicating the hold condition of the call with a 
second client; 

generating a request message, in response to the hold condition, for performing call 
control on behalf of the first client; and 
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transmitting the request message to a content server to instruct the content server to 
transmit content stored therein to the second client. 



26. (Original) A computer-readable medium according to claim 25, wherein the 
receiving step is performed according to an application layer protocol that includes a Session 
Initiation Protocol. 

27. (Original) A computer-readable medium according to claim 25, wherein the content 
in the transmitting step includes at least one of music and messaging. 

28. (Original) A computer-readable medium according to claim 25, wherein the first 
client in the receiving step selects the content for transmission to the second client. 

29. (Previously Presented) A computer-readable medium according to claim 28, wherein 
the selected content is specified in a header of a Session Initiation Protocol (SIP) message from 
the first client. 

30. (Original) A computer-readable medium according to claim 25, wherein the one or 
more processors further perform the step of: 

sending a signaling message to the first client to instruct the first client to cease sending 
media to the second client. 
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X. EVIDENCE APPENDIX 

Appellant is unaware of any evidence that is required to be submitted in the present 
Evidence Appendix. 

XI. RELATED PROCEEDINGS APPENDIX 

Appellant is unaware of any related proceedings that are required to be submitted in the 
present Related Proceedings Appendix. 
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